1. Field of the Invention
The present invention relates to Device Management (DM) in a communication system. More particularly, the present invention relates to techniques for managing devices that are not directly accessible to a DM Server.
2. Description of the Related Art
With the growth in ubiquitous communications technologies and systems, devices are increasing in functionality and complexity. However, with the increase in the functionality and complexity of the devices, a need for the management of the devices has developed. To address that need, the Open Mobile Alliance (OMA) established a Device Management (DM) Working Group to specify protocols and mechanisms that achieve management of devices. The OMA DM Working Group has developed the OMA-DM specification, which defines a two-way protocol between a DM Server and a DM Client associated with a device that is used for remote management of the device. Historically, the devices have been wireless devices, but of late, OMA-DM has begun addressing the remote management needs of wired devices as well. Examples of OMA-DM include the setting of initial configuration information in devices, the subsequent installation and update of persistent information in devices, the retrieval of management information from devices, and the processing of events and alarms generated by devices.
An instance of an interaction between a DM sever and a DM Client is referred to as a DM session and may be initiated by either the DM Client or the DM Server. The DM Client typically embedded at the device and the DM Server manages the device by invoking one or more commands on the DM Client. The DM Client processes the one or more commands and communicates a response back to the DM Server. Communication between the DM Server and the DM Client is implemented via the exchange of Synchronization Markup Language (SyncML) messages.
An example of a communication system employing OMA-DM is described below with reference to FIG. 1.
FIG. 1 illustrates an exemplary communication system employing OMA-DM according to the related art.
Referring to FIG. 1, the exemplary communication system employing OMA-DM may include a wired network 100, a wireless network 102, a wired device 110, a wireless device 112, a DM Server 120, and a DM Authority 130. Each of the wired device 110 and the wireless device 112 has associated therewith a DM Client (not shown). In addition, the DM Authority 130 may be an Operations Support System (OSS). In FIG. 1, solid lines represent physical connectivity and dotted lines represent logical connectivity.
The exemplary communication system employing OMA-DM illustrated in FIG. 1 is merely one of a number of possible implementations. For example, one of the wired network 100 and the wireless network 102 may be omitted. Alternatively, the wired network 100 and the wireless network 102 may be combined. Further, while the DM Server 120 and the DM Authority 130 are shown as connected to the wired network 100, one or both of the DM Server 120 and the DM Authority 130 may alternatively be connected to the wireless network 102.
To facilitate OMA-DM in the communication system illustrated in FIG. 1, a two-way protocol based on the OMA-DM specification is utilized between the DM Server 120 and the DM Client associated with wireless device 112, and between the DM Server 120 and the DM Client associated with the wired device 110. The DM Authority 130 may direct the DM operations of the DM Client associated with each of the wired device 110 and wireless device 112 via the DM Server 120. Only the interaction between the DM Server 120 and a DM Client associated with each of the wired device 110 and wireless device 112, is within the scope of the OMA-DM specification.
An example of a DM Server initiated DM session with a DM Client is described below with reference to FIG. 2.
FIG. 2 is a signal diagram for a DM Server initiated DM session with a DM Client in a communication system according to the related art.
Referring to FIG. 2, the DM Server initiated DM session between a DM Server 202 and a DM Client 204 includes two phases. The first phase is a setup phase 210 and the second phase is a management phase 220. The setup phase 210 includes an exchange of information for authentication and device information. The exchange of information in the setup phase 210 includes one instance of each of three packages, namely Package 0 (212), Package 1 (214), and Package 2 (216). Package 0 (212) is communicated from DM Server 202 to DM Client 204 and is referred to as a Notification Message. Package 1 (214) is communicated from DM Client 204 to DM Server 202. Package 1 (214) includes client initialization information and device information. The client initialization information includes client credentials. Package 2 (216) is sent from DM Server 202 to DM Client 204. Package 2 (216) includes server initialization information and an initial management operation. The server initialization information includes one or more server credentials.
The management phase 220 includes the exchange of one or more instances of two types of packages, namely Package 3 (222), and Package 4 (224). Package 3 (222) is communicated from DM Client 204 to DM Server 202. Package 3 (222) includes client response information to the management operation triggered by Package 2 (216). Package 4 (224) is communicated from DM Server 202 to DM Client 204. Package 4 (224) includes at least one of an additional management operation and one or more additional user interaction commands, if the DM session is continued beyond the Package 2 message 216. Additional cycles of a Package 3 message 222 and a Package 4 message 224 may be transmitted between the DM Server 202 and DM Client 204 until the DM session is terminated.
The OMA-DM protocol supports the notion of DM bootstrapping. DM bootstrapping is the process by which a DM Client transitions from an un-provisioned, empty state, to a state where it is able to initiate a DM session with an authorized DM Server. A DM Client that has already been bootstrapped can be further bootstrapped to enable the DM Client to initiate a DM session with a new DM Server. An example of the OMA-DM architecture is described below with reference to FIG. 3.
FIG. 3 illustrates an OMA-DM architecture according to the related art.
Referring to FIG. 3, the OMA-DM architecture includes a DM Server 340, a DM Client 310 and DM standard Management Objects (MOs) 320. The DM Client 310 and the DM standard MOs 320 are co-located in a device 300. The OMA-DM architecture may include additional structural elements. However, a description of additional structural elements of the OMA-DM architecture is omitted for conciseness.
The DM Server 340 and DM Client 310, which have been described above, communicate via interfaces DM-1 330 and DM-2 332. DM Client 310 communicates via interface DM-5 334 with the DM Standard MOs 320.
The DM protocol defines three standard Management Objects (MOs) 320 that all implementations of a DM Client 310 must support. These DM standard MOs 320 include DMAccount (DMAcc) MO 322, Device Information (DevInfo) MO 324 and Device Details (DevDetail) MO 326.
The DMAcc MO 322 is used to manage information pertaining to bootstrapped DM Server 340. There is a single instance of the DMAcc MO 322 for each bootstrapped DM Server 340. For each DM Server 340 that has been successfully bootstrapped for DM device 310, the corresponding DMAcc MO 322 maintains information on a DM Server IDentifier (ID), connectivity information, server address, server and client credentials, etc. The DevInfo MO 324 provides basic information about the device 300 associated with the DM Client 310. The basic information includes a device ID, a device manufacturer ID, a model ID, and language settings. The DevDetail MO 326 provides additional information about the device 300 associated with the DM Client 310. The additional information includes device type, Original Equipment Manufacturer (OEM), hardware version, firmware version, software version, an indication of whether the device 300 supports optional features (e.g., large-object handling capability), maximum depth of the management tree, maximum total length of any Uniform Resource ID (URI), and maximum total length of any URI segment.
The OMA DM standard specifies that OMA DM MOs be represented as a tree of named nodes. An example of a OMA DMAcc MO node tree according to the related art is provided in FIG. 4 as an example of an OMA DM MO node tree.
FIG. 4 illustrates a DMAcc MO node tree according to the related art.
Referring to FIG. 4, a pictorial description of a tree of named nodes of a DMAcc MO of the related art is shown. The nodes depicted in FIG. 4 are outside the scope of the present disclosure and therefore a description of each node is omitted herein for conciseness. A description of each node depicted in FIG. 4 can be found in section 5.3.1 of version 1.2.1 of the OMA DM Standardized Objects, the entire disclosure of which is hereby incorporated by reference.
Each node in a MO is the potential target for invoking a management operation from the DM Server. In order to perform some remote management action, the DM Server executes an operation on the corresponding node. Nodes are addressed using a URI. The URI of a node is the concatenation of the names of all the nodes from the root of the management tree, using ‘/’ as the delimiter. For example, the URI of the “Name” node of the DMAcc MO shown in FIG. 4 is “Node:<x>/Name”.
As indicated above, OMA-DM was originally developed as a management protocol for hand-held wireless devices. Accordingly, OMA-DM is based on the premise that the DM Server and the DM Client can directly communicate with each other once the DM bootstrapping procedure has been successfully completed. Most commonly, the DM Server requests a DM session with the DM Client by sending a specially formatted Short Message Service (SMS) message to the DM Client. Upon receiving the message, the DM Client authenticates the DM Server and establishes the DM session.
In this era of convergence, as the delineation between wireline and wireless service providers disappears, OMA-DM is being extended to manage categories of devices that have traditionally not supported OMA-DM. For many of these devices, direct communication between the DM Server and the DM Client is not possible. This can happen for various reasons. For example, direct communication between the DM Server and the DM Client may not be possible if the device does not have a publicly routable address, such as a Mobile Subscriber (MS) Integrated Services Digital Network (ISDN) Number (MSISDN). Also, direct communication between the DM Server and the DM Client may not be possible if the device is deployed behind a gateway that provides a Network Address Translation (NAT) and/or firewall functionality. In addition, direct communication between the DM Server and the DM Client may not be possible if the device supports a management protocol other than OMA-DM (i.e. the device does not have an embedded OMA-DM Client).
To address the issues listed above with respect to the direct communication between the DM Server and the DM Client not being possible, a DM Gateway is being investigated in order to address some of the challenges described above. A DM Gateway is an entity that facilitates interaction between a DM Server and a DM Client, at least one of which runs OMA-DM, in situations where direct and unaided interaction between the DM Server and the DM Client is not possible. Unlike in the current OMA-DM paradigm, the DM Gateway is expected to play a major role in the management of devices. Accordingly, a Gateway MO (GwMO) enabler is being developed.
The GwMO enabler, that is being developed, aims to address the issue of managing end devices that are not directly accessible to the DM Server either because the devices are deployed behind a device that provides NAT and/or firewall functionality, or because the devices do not support the OMA-DM protocol. The GwMO enabler defines the following modes of operation for the DM Gateway:                Transparent Mode: The DM Gateway maintains a mapping between the local/private and global/public identity of the device to assist the DM Server in sending a notification to the DM Client deployed behind the DM Gateway. Additionally, the DM Gateway does not participate in the management session that gets established between the DM Server and the DM Client.        Proxy Mode: The DM Gateway manages devices on behalf of the OMA-DM Server. It plays the role of the DM Server for the end device and the role of the DM Client for the DM Server.        Adaptation Mode: The DM Gateway manages non-OMA-DM devices on behalf of the OMA-DM Server over a device supported protocol.        
In the current OMA-DM paradigm, the OMA-DM Client responds to management commands from only those DM Servers with which a trusted relationship has been established via the DM Bootstrapping process. If the OMA-DM Client receives a management command from a DM Server with which it has not been previously bootstrapped, the DM Client silently discards the message.
If the current OMA-DM paradigm is extended to the DM Gateway as well, the DM Gateway will forward messages destined for an end device only if the originating DM Server is one with which the DM Gateway is itself bootstrapped. In other words, the case where the end device is bootstrapped to a DM Server, but the DM Gateway is not bootstrapped to the same DM Server, is not supported. The reason for this is that if an un-bootstrapped DM Server sends a message to the DM Gateway, for forwarding to the end device, the DM Client running on the DM Gateway will simply reject the message and not forward it to the target device.
Accordingly, there is a need for the DM Gateway to forward a command from a DM Server to the target device, even though the DM Gateway itself is not bootstrapped to the DM Server. An example of a case where this functionality is needed is where an end device is pre-bootstrapped to a vendor's diagnostics DM Server but the DM Gateway itself does not have a trusted relationship with the vendor's DM Server.